The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs-website	Ready	Preview, Comment	Apr 24, 2026 2:57pm

Claude finished @renovate[bot]'s task in 2m 25s —— View job

Upstream release docs — toolhive-registry-server v1.4.0

No hand-written doc changes needed. Wrote NO_CHANGES.md at the repo root explaining why.

• Phase 1: Discovery — fetched release, categorized 6 PRs
• Phase 2: Deep dive — verified the one product-facing PR against source at the tag
• Phase 3: Audit existing docs — impact map is empty for hand-written content
• Phase 4: Implementation — wrote NO_CHANGES.md; no prose edits
• Phase 5: Validation — skipped (no edits to validate)
• Phase 6: Committed and pushed

What shipped in v1.4.0

Only one product-facing change, PR #754: GET /v1/registries/{name}/entries admin response now includes title, description, createdAt, updatedAt, and position alongside the existing entryType, name, version, sourceName fields. Verified against internal/service/service.go at the v1.4.0 tag — the RegistryEntryInfo struct matches the PR description exactly.

The remaining PRs are infra-only: obsolete Vercel hook removal (#753), dependency bumps (#756, #757, #758), and the release cut (#755).

Why no prose edits

The admin list-entries response schema is documented solely via the auto-generated swagger at static/api-specs/toolhive-registry-api.yaml — which this PR's release workflow already regenerated (5 new field entries on RegistryEntryInfo, verified in the diff). The only prose reference to /v1/registries/{name}/entries in the docs is at docs/toolhive/guides-registry/authorization.mdx:310-314, where it's cited for authorization scoping rather than response shape. No edit warranted there.

No GAPS.md — the one product-facing PR's "why" is fully resolvable from its PR description (admin UI parity with /v1/sources/{name}/entries).
· Branch

Claude finished @renovate[bot]'s task in 25s —— View job

Editorial review — toolhive-registry-server v1.4.0

• Identify files changed by the previous upstream-release-docs commit
• Determine whether any in-scope docs need an editorial pass
• Post review outcome

Outcome: no editorial review needed

The previous session's commit (281bf01) touched exactly one file — NO_CHANGES.md at the repo root — which is a signal file for the next workflow step and is explicitly out of scope for this review.

The other two files in the PR are also out of scope:

• .github/upstream-projects.yaml — version bump managed by Renovate, not prose.
• static/api-specs/toolhive-registry-api.yaml — auto-generated swagger, regenerated from release assets.

No prose in docs/toolhive/** was modified, so there's nothing to edit. The upstream triage in the previous comment (only one product-facing PR, #754, surfaced purely through the regenerated swagger) stands.
· Branch

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.